home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20041116-20060924 / 000335_fdc@columbia.edu_Fri May 5 11:23:30 2006.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Path: newsmaster.cc.columbia.edu!not-for-mail
  2. From: Frank da Cruz <fdc@columbia.edu>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: using FILE OPEN quadruples memory usage!
  5. Date: 5 May 2006 15:23:17 GMT
  6. Organization: Columbia University
  7. Lines: 50
  8. Message-ID: <slrne5mrf5.lbf.fdc@sesame.cc.columbia.edu>
  9. References: <1146783231.532130.44080@v46g2000cwv.googlegroups.com>
  10. Reply-To: fdc@columbia.edu
  11. NNTP-Posting-Host: sesame.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1146842597 27247 128.59.59.56 (5 May 2006 15:23:17 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 5 May 2006 15:23:17 GMT
  15. User-Agent: slrn/0.9.8.0 (SunOS)
  16. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15592
  17.  
  18. On 2006-05-04, tomviolin <rock_spambust_violin@yahoo.com> wrote:
  19. : I have discovered that using FILE OPEN in C-Kermit 8.0.211 causes
  20. : Kermit's memory usage to quadruple.  The memory usage does not go back
  21. : down after the file(s) are closed, either.
  22. :
  23. : This memory explosion does NOT appear to occur when the "old" OPEN FILE
  24. : method is used, only with the "new" FILE OPEN method.  So it is
  25. : possible to work around it, albeit inconveniently at times.
  26. :
  27. : Further openings of files do not appear to result in further memory
  28. : expansion.  I was able to have multiple files open using FILE OPEN and
  29. : it did not proceed to octuple memory usage, for example.
  30. :
  31. The FILE OPEN code is in ckuus7.c within #ifdef CKCHANNELIO..#endif,
  32. about 1640 lines that I wrote six years ago.  There's a spot where we
  33. malloc z_maxchan times sizeof(struct ckz_file), which includes a filename
  34. buffer of about 1K.  This happens once, the first time FILE OPEN is used.
  35. Probably this storage is never deallocated, since a new file might be
  36. opened at any time.  When I wrote the code, the maximum number of open files
  37. per process (as reported by sysconf) was usually a small number, less than
  38. 100.  Now I see that in current Linuxes, it's more like 1000.  So that would
  39. account for about a megabyte.
  40.  
  41. : I'm using Kermit compiled for ARM with "make linuxnc KFLAGS=-DNOBIGBUF"
  42. : (I'm trying to save memory!)  and running on a 32M embedded board
  43. : running the Linux 2.4.26-ts9 kernel.
  44. :
  45. : How can this be happening if FILE OPEN is simply a front-end for the
  46. : fopen() system call?
  47. :
  48. It does its own bookkeeping, has its own mini-FILE struct for each channel.
  49.  
  50. : I could see memory on the order of kilobytes
  51. : being allocated, but we're talking several megabytes of memory being
  52. : consumed here, just from opening a text file.
  53. :
  54. In Linux (in this case Red Hat AS 4 on AMD-64), if I start Kermit, log debug,
  55. do an FOPEN, exit, and then "grep z_maxchan debug.log" I see:
  56.  
  57.   z_open z_maxchan 1=-2
  58.   z_open z_maxchan 2=1006
  59.   z_open z_maxchan 3=1006
  60.  
  61. 1006 is the number of mini-FILE structs that are allocated.  I can see that
  62. this could be done with a big more finesse.  It wasn't an issue before.  I'll
  63. see what I can do in the next 8.0.212 development upload:
  64.  
  65.   http://www.columbia.edu/kermit/ckdaily.html
  66.  
  67. - Frank